1. Field of the Invention
Embodiments of the present invention relate generally to graphics processing and more specifically to a method and system for presenting image data to a video output device.
2. Description of the Related Art
Over the past decade, the cost of adding on-chip logic to processors has substantially decreased. Consequently, certain types of processors, such as advanced graphics processing units (GPUs), now include functionality not previously available in earlier GPU designs. For example, the newest GPUs are now able to perform geometry processing operations; whereas, such operations traditionally had been left to the central processing unit (CPU). One benefit of this shift in responsibilities is that more graphics processing may now be performed on the GPU instead of the CPU, thereby freeing the CPU to perform other operations.
To fully realize the capabilities of advanced GPUs, certain information needs to be exposed to an application. One example of such GPU-accessible information is the timing information associated with the display of rendered image data to a video output device. More specifically, an application program generally accesses a graphics subsystem via an Application Program Interface (API). An application utilizes the API to specify geometric primitives to the graphics pipeline implemented by the graphics subsystem, and then the resulting fragments are rendered into a framebuffer. Traditionally, this framebuffer is implemented using a double-buffered approach in order to prevent tearing while swapping between subsequent rendered images. Performance hiccups are further reduced by the addition of a queue of buffers known as a flip queue, at the cost of increased latency between image specification and subsequent display. Tearing is further reduced by doing the swap or flip during the vertical blanking interval of the attached video device. Once image specification is complete, the application program then makes a call to the API to initiate a flip operation in order to swap images in the flip queue. At this time the specified framebuffer image is then scanned out to the raster display. The graphics subsystem then proceeds to display the framebuffer but does not provide the application program with any timing information associated with the execution of the flip operation or the delay between image specification and ultimate scanout to the raster display. Therefore, the application program does not know when the scanout actually takes place. In one scenario, when the graphics subsystem falls behind in processing the incoming commands, the vertical blanking time, the time at which a flip can safely take place without image tearing is missed. The graphics subsystem then must wait until the next vertical blanking interval to perform the flip adding a significant delay between the time the command is issued and the time the framebuffer is actually displayed on the video device. Without such timing information, the application program does not know that a flip operation was missed or that it is behind by one or more frames and may need to adjust accordingly. In another scenario, in addition to image data, the graphics subsystem also handles metadata (e.g., sound data) from an external source and is required to synchronize the two before presenting the combined data to one or more output devices. Here, without any timing information from the graphics subsystem, the application program lacks the requisite intelligence to ensure synchronization of both the image data and the metadata or to recover from system performance glitches.
As the foregoing illustrates, what is needed in the art is an improved method and system for obtaining and specifying timing information that addresses at least the problems discussed above.